To understand how firewalls work, consider some of the subjects discussed earlier in this book. First, most simple authentication procedures use the IP address as an index. The IP address is the most universal identification index on the Internet. This address can be either a static or dynamic address:
When a connection is made between your machine and a remote machine, various dialogs may ensue. I discussed some of those dialogs in Chapter 6, "A Brief Primer on TCP/IP." A common one--which you are apt to remember--is the TCP/IP three-way handshake. At any rate, such dialogs occur, during which time your IP is known by the target machine.
Under normal circumstances, where no firewall or other superseding utility (such as TCP_Wrapper) has been installed, the dialog between your machine and the remote machine occurs directly (see Figure 27.1).
FIGURE 27.1.
The route of information.
When I say that information travels directly, that is a very qualified term. As you can see, the process (even without security measures) is complex:
2. Information travels from your machine to a machine on
the provider's network. From there, the information travels through an
Ethernet cable (or other means of transport) to the main server of Your
Network.
3. The server of Your Network passes this information to Router 1, which promptly pours the information through the telephone line (or other high-speed connection) to the Internet at large.
4. The information travels across the Internet (passing through many routers and gateways along the way), ultimately reaching Router 2. Router 2 pipes the information into Their Server; the information is then served via Ethernet (or other transport) to Their Network.
If neither side has installed security measures, the path is deemed (for all purposes) direct. Router 2, for example, allows packets from any source (IP) address to travel directly to Their Server and ultimately, to Their Network. At no point during that travel do the packets meet an obstacle. This is a completely insecure situation. However, for many years, this was the standard. Today, the type of situation illustrated in Figure 27.1 is too dangerous. Over the years, network engineers considered a wide range of solutions, including the firewall.
NOTE: I have greatly simplified the network outlay design by providing only relevant details. In practice, there might be all sorts of devices located between Your Network and Their Network.
Suppose the architect knows a Web server must exist on the host network. This Web server will obviously accept connections from almost any IP address. A restricted area, therefore, must be created for that server. In other words, in providing Web services from the host network, the architect must ensure that the Web server does not endanger the remaining portions of the network. Likewise, incoming mail is also an issue.
If hardware, a firewall can (and often does) consist of no more than a router. As you will learn in Chapter 28, "Spoofing Attacks," routers have advanced security features, including the capability to screen IP addresses. This screening process allows you to define which IP addresses are allowed to connect and which are not.
Other implementations consist of both hardware and software. (These can get pretty eclectic. I have seen people using 386 boxes with shareware firewall/bridge products on them.)
In any event, all firewalls share a common attribute: the capability to discriminate or the capability to deny access generally based on source address.
In a router-based firewall implementation, the source address of each incoming connection (that is, the address from which the packets originated) is examined. After each IP source address has been identified, whatever rules the architect has instituted will be enforced. For example, perhaps the architect decides that no network traffic will be accepted from any address within Microsoft Corporation. Thus, the router rejects any packets forwarded from microsoft.com. These packets never reach the internal server or the network beneath it.
Router-based firewalls are fast. Because they only perform cursory checks on the source address, there is no real demand on the router. It takes no time at all to identify a bad or restricted address. Nevertheless, the speed comes with a price: Router-based firewalls use the source address as an index. That means (barring controls against such access) packets sent from forged source addresses can gain at least some level of access to your server.
NOTE: Routers are about the size of a small printer. Generally, at the back of the router are connection points for Ethernet and digital telephone lines. Use these connection points to connect the telephone line (T1, T3, and so on) and Ethernet to your server. Routers are configured using special software. In most instances, the software is quite easy to use. Most newer implementations are controlled through a windowed interface (such as the X Window system, OpenWindows, and so on). Routers range in price (from used to new) from $600 to $1800.
In fairness, many packet-filtering techniques can be employed with router-based firewalls that shore up this weakness. The IP address header is not the only field of a packet that can be trapped by a router. As packet-filtering technology becomes more sophisticated, so do the schemes or rules employed by an administrator. One can now even apply rules related to state information within packets, using indexes such as time, protocol, ports, and so forth.
However, these are not the only deficiencies of packet-filtering, router-based firewalls. For example:
Cross Reference: For an excellent discussion of the fields that can be filtered, as well as a comprehensive look at packet filtering, "Network (In)Security Through IP Packet Filtering" by D. Brent Chapman is a must. Find it online at http://www.unix.geek.org.uk/~arny/pktfilt.ps.
Wack discusses RPC as a potential problem because the ports can be assigned dynamically at startup. However, in most cases, this type of filtering (appropriately called protocol filtering) is not a problem. Very sophisticated schemes can be implemented in protocol filtering, and these rely primarily on the port called by the remote host.
Cross Reference: The preceding paragraph is excerpted from "Problems with Packet Filtering Routers" by John Wack. It can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node51.html.
Cross Reference: For an excellent discussion of protocol filtering and packet filtering in general, check out "Packet Filtering in an IP Router" by Bruce Corbridge, Robert Hening, and Charles Slater. This paper offers an inside look at exactly how packet filtering is accomplished in Telebit routers. More importantly, the document takes you through the design and implementation of the router. You can find it online at http://www.alw.nih.gov/Security/FIRST/papers/firewall/cslater.ps.
Cross Reference: TCP_Wrappers is available online at ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.4.tar.gz.
Cross Reference: You can find information about NetGate at http://hosaka.smallworks.com/netgate/packetfiltering.html.
Cross Reference: The Internet Packet Filter can be found at ftp://coombs.anu.edu.au:/pub/net/kernel/ip_fil3.0.4.tar.gz.
Cross Reference: The document announcing Argus's availability can be found online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/argus-1.5.announce. The tool can be obtained online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/.
Cross Reference: Netlog is available online at ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.
Cross Reference: Netman is available online at ftp://ftp.cs.curtin.edu.au/pub/netman/.
There are other platform-specific packet filters. One well-known one is packetfilter, which runs on Ultrix 4.3. It is kernel resident.
Cross Reference: NOCOL/NetConsole v.4.0 is available online at ftp://ftp.navya.com/pub/vikas/nocol.tar.gz.
Nonetheless, many of these tools, although capable of examining and monitoring packet traffic, cannot institute access-control policies. And that is the whole purpose of a firewall. It gives the administrator the ability to finely control who can (and cannot) access the network.
Cross Reference: The man page for packetfilter is available online at http://198.233.42.11/ cgi-bin/man2html/packetfilter(4).
The advantage of the application-gateway proxy model is the lack of IP forwarding. More importantly, more controls can be placed on the patched connection. Finally, such tools often offer very sophisticated logging facilities. Again, there is no such thing as a free lunch. As you might expect, this gateway scheme has a cost in terms of speed. Because each connection and all packet traffic are accepted, negotiated, translated, and reforwarded, this implementation can be slower than router-based packet filtering.
IP forwarding occurs when a server that receives an external request from the outside world forwards that information in IP format to the internal network. Leaving IP forwarding enabled is a fatal error. If you allow IP forwarding to occur, a cracker can get in from the outside and reach workstations on your internal network.
Another disadvantage of this scheme is that a proxy application must be created for each networked service. Thus, one is used for FTP, another for Telnet, another for HTTP, and so forth. As John Wack explains in his article titled "Application Gateways":
Cross Reference: "Application Gateways" by John Wack can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node52.html.
The beautiful thing about the FWTK is that it has excellent access control built into its design. For example, you can allow or deny access (connection) from a network, a part of a network, or even a single address. In this respect, it has granular access control.
The reason I mention the TIS FWTK is because it was the first, full-fledged firewall of this class. It was a ground breaker in the firewall field.
Cross Reference: Before you get the TIS FWTK, you should probably examine a posting of a message from Marcus Ranum, one of the developers of TIS FWTK. This is a short, entertaining document that gives some insight into how the FWTK started. That document is located online at http://www.micrognosis.com/~nreadwin/fwtk/history.txt.
Cross Reference: Obtain a copy of the TIS Firewall Tool Kit at ftp://ftp.tis.com/pub/firewalls/toolkit/dist/.
Cross Reference: The FWTK requires a UNIX system and a C compiler. Moreover, although the FWTK is known to compile on SunOS and BSD without problems, configuration issues exist for Linux. To sort out these problems quickly, there is no better document than "Creating a Linux Firewall using the TIS Toolkit" by Benjamin Ewy. That document is located online at http://www.ssc.com/lj/issue25/1204.html. Patches for use with the FWTK on Linux are located online at ftp://ftp.tisl.ukans.edu/pub/security/firewalls/fwtkpatches.tgz.
It is my opinion that application-gateway systems (proxy-based firewalls) are more secure. This is because there is no IP forwarding scheme. That means IP packets from the void cannot reach any machine on your internal network.
Cross Reference: "Thinking About Firewalls," also by Marcus Ranum, is a very good document about firewalls in general. This document details the types of firewalls that can be implemented and their advantages and disadvantages. It can be found online at http://hp735c.csc.cuhk.hk/ThinkingFirewalls.html.
NOTE: Another extremely popular firewall in this class is SOCKS, which is based on the application-proxy model. The connect request is intercepted by SOCKS and translated. Thus, a direct connection never occurs between your network and the outside world. SOCKS is of great significance because it is so well established that support for it is already included in many browser packages, most notably Netscape Navigator.
Cross Reference: There is a very comprehensive coverage of SOCKS technology on the Internet. The document is so well designed and written that anyone can get a solid grasp of how SOCKS works in just a few moments. That document is at http://www.socks.nec.com/introduction.html.
Theoretically, a firewall is the most stringent security measure you can implement (barring, of course, disconnecting your system from the Internet). Nevertheless, issues regarding this stringent security environment remain. One is that security with a firewall can be configured so stringently that it can actually impair the process of networking. For example, some studies suggest that the use of a firewall is impractical in environments where users critically depend on distributed applications. Because firewalls implement such a strict security policy, these environments become bogged down. What they gain in security, they lose in functionality. Universities are a perfect example of this type of environment. Research in universities is often conducted where two or more departments (often on network segments located far from each other) are involved in the compilation of data (and corroboration of research efforts). In these environments, it is very difficult to work under such tight security restraints.
CAUTION: Your firewalled network will not be entirely invisible. At least one scanner, called Jakal, can scan for services running behind a firewall. Jakal, a stealth scanner, will scan a domain (behind a firewall) without leaving any trace of the scan. According to the authors, all alpha test sites were unable to log any activity (though it is reported that "some firewalls did allow SYN | FIN to pass through"). Refer to Chapter 9, "Scanners," for the scoop on that utility.
A second issue regarding firewalls is that they lead to placing most of your eggs in one basket. Because a firewall is your face to the void, a breach can cause your internal network to be easily destroyed. That is, firewalls can foster a climate in which they are the only real access control and security you have. Firewalls are almost always described as the bottleneck of a network, where all authentication is to be done. This seems suitable as long as firewalls are infallible. But what if they aren't? What if a technique is discovered to crack any firewall? Networks that rely on firewalls would be completely exposed, and odds of survival would be slim.
Before you construct a firewall, you should undertake some serious research. When you construct a firewall, you must know your network intimately. This requires true organization. Various network segments (either on the same network or different ones) will need to communicate with each other. These networks can communicate through automated processes or human interaction. Automated processes might prove easy to accommodate. Human-initiated processes, however, can differ dramatically.
For some organizations, a firewall is just plain impractical. ISPs are within this class. One could quickly lose customers by instituting harsh security policies. Indeed, some contend that firewalls are not needed. These people argue that solid system administration practices will render the same benefit as a firewall, without slowing the network or making connections difficult.
There are other problems with establishing a firewall as well. If FTP, Telnet, Gopher, HTTP, RPC, rlogin, and NFS were the only protocols that the Internet would ever use, a firewall would pose only limited problems with access. After all, proxies have been written for all of these applications. The problem is, these are not the only services; new services crop up each month. Thus, to provide your internal users with effective Internet access, you must keep up with the applications now emerging. Proxies for such services will generally be obtainable, but after the new service or protocol has already been on the market for some time. Of course, some time is generally only a few months, but during those months, your internal users will fuss.
2. Developing policies
3. Having adequate tools
4. Using those tools effectively
5. Testing the configuration
It is important to maintain your tact during this process. You will often run into users who insist, "We've been doing it this way for 10 years now." Even though you have great authority (because security is such a serious concern), you should work with these people as much as possible. It is not necessary that they understand the process in full. Nevertheless, if you intend to restrict or otherwise hamper their ability to reach out into the void, you should explain why to them. The last thing you need is to anger (or otherwise foster resentment within) local users. Rather, you need their support because after you finish building your firewall, you will distribute a policy. How closely local users follow that policy will dramatically affect the security of your network. For example, if insecure modems are located in this or that department, this is a potential hole. If you have dealt tactfully with local users, you will probably have nothing to fear. However, if you have issued Draconian decrees, you can be pretty sure that local users will trip you up.
So, your first job is to determine what can and cannot be restricted. A list should be made of all nonstandard protocols that are essential between this network and any other. That done, you can begin to get a picture of how the firewall will be built (at least, the local access policies). Determining whom (or what) not to let in is a little less perplexing. More than likely, you will want to restrict connections from any network known to forward unsolicited e-mail, sexual content, or other materials not related to your business. You might also want to restrict addresses that are known hacking or cracking havens.
NOTE: I hear folks dispute this all the time. They insist that no one can simply install a modem on a machine. Why not? I have seen it happen in many companies. There is nothing in a policy alone that will prevent an employee from doing so. Furthermore, on networks with PC-based workstations, many machines or workstations have internal modems to begin with. I dealt with one client who had a Novell NetWare network from the old days. Even the client was unaware that some machines had modems (1200 baud, of course).
NOTE: I would restrict all known hacking and cracking addresses. For example, a well- known hacking group recently conducted a wide scan of U.S. domains, purportedly under the guise of security research. This caused a stir in security-related mailing lists and newsgrouqa and rightly so.
The second task, finding a hole in the firewall, is a bit more difficult. Cracker studies indicate that if there is such a hole, it exists as a result of human error (or rather, misconfiguration on the part of the system administrator). This is not a rare occurrence. One must recognize that no matter what platform is in use, this is a problem. In UNIX networks, it can be at least partially attributed to the fact that UNIX is so complex. There are hundreds of native applications, protocols, and commands. This is before you begin to construct a firewall. Failed firewall implementation on Microsoft platforms might occur for other reasons (for instance, because administrators might be unfamiliar with TCP/IP). In either case, human error is a likely possibility. For this reason, companies should be extremely selective when choosing the personnel responsible for implementing the firewall. Some common cracker agendas include
Cross Reference: Decoys bear at least a fleeting resemblance to the box (reportedly built by Steven Bellovin) described in the article by B. Cheswick titled "An Evening With Berferd In Which a Cracker is Lured, Endured and Studied." This article can be found online at ftp://research.att.com/dist/internet_security/berferd.ps.
Finally, firewalls have been bypassed or broken in the past. The Quake site at Crack dot Com is one such example. Although relatively little information has been distributed about how the crack was accomplished, it was reported in Wired that:
It is possible to identify the type of firewall being run on a given server. However, printing that is beyond the level of irresponsibility to which I am prepared to stoop just to sell a book. I will say this: You can do it with a combination of the Jakal scanner and a script written to jackhammer a site. Which addresses are blocked matters less than how they are blocked (that is, you need to elicit responses from the firewall).
Cross Reference: The preceding paragraph is excerpted from "Hackers Hack Crack, Steal Quake," an article, by Annaliza Savage, that appeared in Wired. Find the article online at http://www.wired.com/news/culture/story/1418.html.
Company: Raptor Systems
Specs: http://www.raptor.com/products/brochure/40broch.html
Home: http://www.raptor.com
Raptor has been around a long time. It introduced its line of firewall products in 1991. The company has a solid reputation. As stated in its online company description:
Its products combine a wide range of firewall techniques, including heavy logging; specialized, event-triggered treatment of suspicious activity; and extremely granular access controls. This family of firewall products integrates application proxies.
Cross Reference: Check out Raptor's online company description at http://www.raptor.com/products/brochure/40broch.html#aboutraptor.
Check Point Firewall and Firewall-1
Company: Check Point Software Technologies Ltd.
Specs: http://www.checkpoint.com/products/firewall/intro.html
Home: http://www.checkpoint.com/
Check Point is based in Israel and was founded in 1993. It also has outposts in eight U.S. cities, including Redwood City, Los Angeles, New York, and others. The product line offers cross-platform support.
One of the more interesting elements of Check Point Firewall-1 is that it includes time object control. That is, one can assign certain times of the day to perform certain access restrictions. Firewall-1 also has provisions to distribute process loads among a series of workstations.
Cross Reference: Articles and press releases about Check Point are located online at http://www.checkpoint.com/press/index.html. More important information about Check Point's flagship product is located at http://www.checkpoint.com/products/white/index.html.
SunScreen
Company: Sun Microsystems
Specs: http://www.sun.com/security/overview.html
Home: http://www.sun.com
Sun's SunScreen is comprised of a series of products. In the SunScreen product line, Sun has addressed one of the primary problems I mentioned previously: If your bottleneck is broken, your network is completely exposed. Sun's new line of products will likely revolutionize the firewall industry (certainly on the Sun platform). The chief products include
Cross Reference: Some specs for SunScreen EFS are located online at http://www.sun.com/security/prod_spec.html.
IBM Internet Connection Secured Network Gateway
Cross Reference: Check out SunScreen SKIP online at http://www.sun.com/security/skip.html.
Company: Internal Business Machines (IBM)
Specs: http://www.ics.raleigh.ibm.com/firewall/info.htm
Home: http://www.ics.raleigh.ibm.com/firewall/overview.htm
This product is designed for AIX. Like Sun's SunScreen product line, it is capable of hiding the IPs of your internal network. It supports application proxies and has exceptional logging and reporting capabilities, as well as isolated Web services.
Cisco PIX Firewall
Cross Reference: For an extremely comprehensive study of IBM's Internet Connection Secured Network Gateway, visit http://www.ncsa.com/fpfs/ibm.html at NCSA.
Company: Cisco Systems
Specs: http://www.cisco.com/univercd/data/doc/cintrnet/prod_cat/pcpix.htm
Home: http://www.cisco.com
This firewall relies not on application proxies (which can consume additional network resources and CPU time) but instead on a secure operating system within the hardware component itself. Special features include an HTML configuration and administration control tool, IP concealment and non-translation, easy configuration, and support for 16,000 instant connections.
The future of firewall technology is a very interesting field indeed. However, if you have truly sensitive data to protect (and it must be connected to the Internet), I advise against using a firewall (commercial or otherwise) as your only means of defense.
Internet Firewalls. Scott Fuller and Kevin Pagan. Ventana Communications Group Inc. ISBN: 1-56604-506-1. 1997.
Building Internet Firewalls. D. Brent Chapman and Elizabeth D. Zwicky. O'Reilly & Associates. ISBN: 1-56592-124-0. 1995.
Firewalls and Internet Security : Repelling the Wily Hacker. William R. Cheswick and Steven M. Bellovin. Addison-Wesley Professional Computing. ISBN: 0-201-63357-4. 1994.
Actually Useful Internet Security Techniques. Larry J. Hughes, Jr. New Riders. ISBN: 1-56205-508-9. 1995.
Internet Security Resource Library: Internet Firewalls and Network Security, Internet Security Techniques, Implementing Internet Security. New Riders. ISBN: 1-56205-506- 2. 1995.
Firewalls FAQ. Marcus J. Ranum.
NCSA Firewall Policy Guide. Compiled by Stephen Cobb, Director of Special Projects. National Computer Security Association. Comparison: Firewalls. Comprehensive comparison of a wide variety of firewall products. LANTimes. June 17, 1996. There Be Dragons. Steven M. Bellovin. Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray Hill, NJ. August 15, 1992.Rating of Application Layer Proxies. Michael Richardson.
Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls. John P. Wack and Lisa J. Carnahan. National Institute of Standards and Technology. SQL*Net and Firewalls. David Sidwell and Oracle Corporation. Covert Channels in the TCP/IP Protocol Suite. Craig Rowland. Rotherwick & Psionics Software Systems Inc. If You Can Reach Them, They Can Reach You. William Dutcher. A PC Week Online Special Report, June 19, 1995. Packet Filtering for Firewall Systems. February 1995. CERT (and Carnegie Mellon University). Network Firewalls. Steven M. Bellovin and William R. Cheswick. IEEECM, 32(9), pp. 50-57, September 1994.Session-Layer Encryption. Matt Blaze and Steve Bellovin. Proceedings of the Usenix Security Workshop, June 1995.
A Network Perimeter With Secure External Access. Frederick M. Avolio and Marcus J. Ranum. An extraordinary paper that details the implementation of a firewall purportedly at the White House.
Packets Found on an Internet. Steven M. Bellovin. Lambda. Interesting analysis of packets appearing at the application gateway of AT&T. Using Screend to Implement TCP/IP Security Policies. Jeff Mogul. Rotherwick and Digital. Firewall Application Notes. Livingston Enterprises, Inc. Good document that starts by describing how to build a firewall. It also addresses application proxies, Sendmail in relation to firewalls, and the characteristics of a bastion host. X Through the Firewall, and Other Application Relays. Treese/Wolman. Digital Equipment Corp. Cambridge Research Lab. Intrusion Protection for Networks 171. BYTE Magazine. April, 1995.Benchmarking Methodology for Network Interconnect Devices (RFC 1944). S. Bradner and J. McQuaid.
Firewall Performance Measurement Techniques: A Scientific Approach. Marcus Ranum. Warding Off the Cyberspace Invaders. Amy Cortese. Business Week. 03/13/95.Vulnerability in Cisco Routers Used as Firewalls. Computer Incident Advisory Capability Advisory: Number D-15.
WAN-Hacking with AutoHack--Auditing Security behind the Firewall. Alec D.E. Muffett. Written by the author of Crack, the famous password-cracking program. Extraordinary document that deals with methods of auditing security from behind a firewall (and auditing of a network so large that it contained tens of thousands of hosts). Windows NT Firewalls Are Born. PC Magazine. February 4, 1997. IP v6 Release and Firewalls. Uwe Ellermann. 14th Worldwide Congress on Computer and Communications Security. Protection, pp. 341-354, June 1996.The SunScreen Product Line Overview. Sun Microsystems.
Product Overview for IBM Internet Connection Secured Network Gateway for AIX, Version 2.2. IBM firewall information. The Eagle Firewall Family. Raptor firewall information. Secure Computing Firewall&tm; for NT. Overview. Secure Computing. Check Point FireWall-1 Introduction. Check Point Technologies firewall information. Cisco PIX Firewall. Cisco Systems firewall information. Protecting the Fortress From Within and Without. R. Scott Raynovich. LAN Times. April 1996. Internet Firewalls: An Introduction. Firewall white paper. NMI Internet Expert Services. Features of the CentriTM Firewall. Centri firewall information. Five Reasons Why an Application Gateway Is the Most Secure Firewall. Global Internet.
© Copyright, Macmillan Computer Publishing. All rights reserved.